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Abstract 

- - - _ This paper presents a new C++ framework, Delphes, performing a fast multipurpose detector response simulation. The simulation 
includes a tracking system, embedded into a magnetic field, calorimeters and a muon system, and possible very forward detectors 
arranged along the beamline. The framework is interfaced to standard file formats (e.g. Les Houches Event File or HepMC) and 
outputs observables such as isolated leptons, missing transverse energy and collection of jets which can be used for dedicated 
analyses. The simulation of the detector response takes into account the effect of magnetic field, the granularity of the calorimeters 
Q^and subdetector resolutions. A simplified preselection can also be applied on processed events for trigger emulation. Detection 
of very forward scattered particles relies on the transport in beamlines with the Hector software. Finally, the FROG 2D/3D event 
display is used for visualisation of the collision final states. 
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1. Introduction 

Multipurpose detectors at high energy colliders are very 
complex systems. Precise data analyses require a full detector 
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simulation, including transport of the primary and secondary 
particles through the detector material accounting for the var- 
ious detector inefficiencies, the dead material, the imperfec- 
tions and the geometrical details. Their simulation is in gen- 
eral performed by means of the GEANT [1] package and final 
observables used for analyses usually require sophisticated re- 
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construction algorithms. 

This complexity can only be handled by large collabora- 
tions. Phenomenological studies, looking for the observability 
of given signals, require in general only fast but realistic es- 
timates of the expected signal signatures and their associated 
backgrounds. 

In this context, a new framework, called Delphes [2], has 
been developped, for a fast simulation of a general-purpose col- 
lider experiment. Using this framework, observables such as 
cross-sections and efficiencies after event selection can be esti- 
mated for specific reactions. Starting from the output of event 
generators, the simulation of the detector response takes into 
account the subdetector resolutions, by smearing the kinemat- 
ics of final-state particles (i.e. those considered as stable by the 
event generator '). 

Delphes includes the most crucial experimental features, 
such as (Fig. 1): 

1 . the geometry of both central and forward detectors, 

2. the effect of magnetic field on tracks, 

3. the reconstruction of photons, leptons, jets, fe-jets, r-jets 
and missing transverse energy, 

4. a lepton isolation, 

5. a trigger emulation, 

6. an event display. 

Although Delphes yields much realistic results than a sim- 
ple "parton-level" analysis, it has some limitations. Detec- 
tor geometry is idealised, being uniform, symmetric around 
the beam axis, and having no cracks nor dead material. Sec- 
ondary interactions, multiple scatterings, photon conversion 
and bremsstrahlung are also neglected. 

Several common datafile formats can be used as input in 
Delphes [a], in order to process events from many different gen- 
erators. Delphes creates output data in a ROOT ntuple [3]. This 
output contains a copy of the generator-level data, the analysis 
data objects after reconstruction, and possibly the results of the 
trigger emulation [b]. In option Delphes can produce a reduced 
output file in * . Ihco text format, which is limited to the list of 
the reconstructed high-level objects in the final states [c]. 

2. Simulation of the detector response 

The overall layout of the multipurpose detector simulated by 
Delphes is shown in Fig. 2. It consists in a central tracking 
system (TRACKER) surrounded by an electromagnetic and a 
hadron calorimeters (ECAL and HCAL, each with a central re- 
gion and two endcaps) and two forward calorimeters (FCAL). 



'in the current Delphes version, particles other than electrons (e*), photons 
(y), muons (/i*), neutrinos (v^, v,, and v^) and neutralinos ai'e simulated as 
hadrons for their interactions with the calorimeters. The simulation of stable 
particles beyond the Standard Model should therefore be handled with care [d]. 



Table 1: Default extension in pseudorapidity r] of the different subdetectors. 
Full azimuthal {if)) acceptance is assumed. 



ri (f> 


TRACKER 


[-2.5; 2.5] 


[-n; 7t] 


ECAL, HCAL 


[-1.7; L7] 


[-n; 7t] 


ECAL, HCAL endcaps 


[-3;-1.7]& [L7;3] 


[-n; 7t] 


FCAL 


[-5; -3] & [3; 5] 


[-n; 7t] 


MUON 


[-2.4; 2.4] 


[-n; 7t] 



Finally, a muon system (MUON) encloses the central detector 
volume. 

A detector card [e] allows a large spectrum of running 
conditions by modifying basic detector parameters, including 
calorimeter and tracking coverage and resolution, thresholds 
or jet algorithm parameters. Even if Delphes has been devel- 
opped for the simulation of general-purpose detectors at the 
LHC (namely, CMS and ATLAS), this input parameter file in- 
terfaces a flexible parametrisation for other cases, e.g. at future 
linear colliders [f]. The geometrical coverage of the various 
subsystems used in the default configuration are summarised in 
Tab. L 




Figure 2: Profile of layout of the generic detector geometry assumed in 
Delphes. The innermost layer, close to the interaction point, is a central track- 
ing system (pink). It is surrounded by a central calorimeter volume (green) 
with both electromagnetic and hadronic sections. The outer layer of the cen- 
tral system (red) is muon system. In addition, two end-cap calorimeters (blue) 
extend the pseudorapidity coverage of the central detector. Additional forward 
detectors ai'e not depicted. 



2.1. Magnetic field 

In addition to the subdetectors, the effects of a solenoidal 
magnetic field are simulated for the charged particles [h]. 
This affects the position at which charged particles enter the 
calorimeters and their corresponding tracks. The field exten- 
sion is limited to the tracker volume and is in particular not ap- 
plied for muon chambers. This is not a limiting factor since the 
magnetic field is not used for the muon momentum smearing. 

2.2. Tracks reconstruction 

Every stable charged particle with a transverse momentum 
above some threshold and lying inside the detector volume cov- 
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Figure 1: Flow chart describing the principles behind Delphes. Event files coming from external Monte Carlo generators ai'e read by a converter stage (top). The 
kinematics variables of the final-state particles are then smeared according to the tunable subdetector resolutions. Tracks ai'e reconstructed in a simulated solenoidal 
magnetic field and calorimetric cells sample the energy deposits. Based on these low-level objects, dedicated algorithms are applied for particle identification, 
isolation and reconstruction. The transport of very forwai'd particles to the near-beam detectors is also simulated. Finally, an output file is written, including 
generator-level and analysis-object data. If requested, a fully parametrisable tiigger can be emulated. Optionally, the geometry and visuahsation files for the 3D 
event display can also be produced. All user parameters are set in the Detector/Smearing Card and the Trigger Card. 



ered by the tracker provides a track. By default, a track is as- 
sumed to be reconstructed with 90% probability if its transverse 
momentum pj is higher than 0.9 GeV/c and if its pseudorapid- 
ity |?7| < 2.5 [i]. No smearing is currently applied on track 
parameters. For each track, the positions at vertex (77, 0) and at 
the entry point in the calorimeter layers {rj, <p)caio are available. 

2.3. Calorimetric cells 

The response of the calorimeters to energy deposits of incom- 
ing particles depends on their segmentation and resolution, as 



well as on the nature of the particles themselves. In CMS and 
ATLAS detectors, for instance, the calorimeter characteristics 
are not identical in every direction, with typically finer resolu- 
tion and granularity in the central regions [5, 6]. It is thus very 
important to compute the exact coordinates of the entry point of 
the particles into the calorimeters, in taking the magnetic field 
effect into account. 

The smallest unit for geometrical sampling of the calorime- 
ters is a cell; it segments the (;;, (p) plane for the energy mea- 
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surement. No longitudinal segmentation is available in the sim- 
ulated calorimeters. Delphes assumes that ECAL and HCAL 
have the same segmentations and that the detector is symmetric 
in (j) and with respect to the 77 = plane [1]. Fig. 3 illustrates the 
default calorimeter segmentation. 



Calorimeter segmentation | 




3 4 5 

r| segmentation 



Figure 3: Default segmentation of the calorimeters in the (t;, (A) plane. Only 
the central detectors (ECAL, HCAL) and FCAL are considered. <!> angles are 
expressed in radians. 



The calorimeter response is parametrised through a Gaussian 
smearing of the accumulated cell energy with a variance cr; 



(1) 



where S , and C are the stochastic, noise and constant terms, 
respectively, and © stands for quadratic additions [j]. 

In the default parametrisation, ECAL and HCAL are as- 
sumed to cover the pseudorapidity range \ti\ < 3, and FCAL 
between 3.0 and 5.0, with different response to electrons and 
photons, or to hadrons. Muons and neutrinos are assumed not 
to interact with the calorimeters [d]. The default values of the 
stochastic, noise and constant terms are given in Tab. 2. 



Table 2: Default values for the resolution of the central and forward calorime- 
ters (for both electromagnetic and hadronic parts). Resolution is parametrised 
by the stochastic (S), noise (N) and constant (C) terms (Eq. 1) [g]. 



assumed to leave their entire energy interactin the hadronic 
parts (HCAL and FCAL, had.). Some long-living particles, 
such as the K'^ and A's, with lifetime cr smaller than 10 mm 
are considered as stable particles by the generators although 
they may decay before reaching the calorimeters. The energy 
smearing of such particles is therefore performed using the ex- 
pected fraction of the energy, determined according to their de- 
cay products, that would be deposited into the ECAL (^ecal) 
and into the HCAL (^hcal)- Defining F as the fraction of the 
energy leading to a HCAL deposit, the two energy values are 
given by 

^HCAL - E X F 
Eecal^Ex{1-F) 



(2) 



where < F < 1. The resulting calorimetry energy mea- 
surement given after the application of the smearing is then 
E = £hcal + £^ECAL- For /iT" and A hadrons, the energy fraction 
is F is assumed to be 0.7 [k]. 

No sharing between neighbouring cells is implemented when 
particles enter a cell very close to its geometrical edge. Due to 
the finite segmentation, the smearing, as defined in Eq. 1, is ap- 
plied directly on the accumulated electromagnetic and hadronic 
energies of each calorimetric cell. The calorimetric cells enter 
in the calculation of the missing transverse energy (MET), and 
are used as input for the jet reconstruction algorithms. 

The output file created by Delphes [m] stores the final collec- 
tions of particles (e=^, ju'^, 7) and objects (light jets, ^7-jets, r-jets, 
Ej"'^). In addition, collections of tracks, calorimetric cells and 
hits in the very forward detectors (ZDC, RP220 and FP420, see 
Sec. 5) are added. 



3. High-level reconstruction 

While electrons, muons and photons are easily identified, 
other quantities are more difficult to evaluate as they rely on 
sophisticated algorithms (e.g. jets or missing energy). 

For most of these objects, their four-momentum and related 
quantities are directly accessible in Delphes output (£, p, pj, rj 
and (p). Additional properties are available for specific objects 
(like the charge and the isolation status for e"^ and yt/^, the re- 
sult of application of fe-tag for jets and time-of-flight for some 
detector hits). 





S (GeV'/'') 


(GeV) 


C 


ECAL 


0.05 


0.25 


0.0055 


ECAL, end caps 


0.05 


0.25 


0.0055 


FCAL, e.m. part 


2.084 





0.107 


HCAL 


1.5 





0.05 


HCAL, end caps 


1.5 





0.05 


FCAL, had. part 


2.7 





0.13 



Electrons and photons are assumed to leave their energy 
in the electromagnetic parts of the calorimeters (ECAL and 
FCAL, e.m.), while charged and neutral final-state hadrons are 



3.1. Photon and charged lepton 

From here onwards, electrons refer to both positrons (e^) and 
electrons (e ), and charged leptons refer to electrons and muons 
(//^), leaving out the r"^ leptons as they decay before being de- 
tected. 

The electron, muon and photon collections contains only the 
true final-state particles identified via the generator-data. In ad- 
dition, these particles must pass fiducial cuts taking into account 
the magnetic field effects and some additional reconstruction 
cuts. 

Consequently, no fake candidates enter these collections. 
However, when needed, fake candidates can be added into the 
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collections at the analysis level, when processing Delphes out- 
put data. As effects like bremsstrahlung are not taken into ac- 
count along the lepton propagation in the tracker, no clustering 
is needed for the electron reconstruction in Delphes. 

Electrons and photons 

Real electron (e=^) and photon candidates are associated to 
the final-state collections if they fall into the acceptance of the 
tracking system and have a transverse momentum above some 
threshold (default: pj > lOGeV/c). De/p/iei assumes a perfect 
algorithm for clustering and Brehmstrahlung recovery. Electron 
energy is smeared according to the resolution of the calorimet- 
ric cell where it points to, but independently from any other 
deposited energy in this cell. Electrons and photons may create 
a candidate in the jet collection. The {rj, <p) position at vertex 
corresponds to corresponding track vertex. 

Muons 

Generator-level muons entering the muon detector accep- 
tance (default: -2.4 < J] < 2.4) and overpassing some thresh- 
old (default: pr > 10 GeV/c) are considered as good candi- 
dates for analyses. The application of the detector resolution 
on the muon momentum depends on a Gaussian smearing of 
the pt [n]. Neither rj nor variables are modified beyond the 
calorimeters. Multiple scattering is neglected. This implies that 
low energy muons have in Delphes a better resolution than in 
a real detector At last, the particles which might leak out of 
the calorimeters into the muon systems (punch-through) are not 
considered as muon candidates in Delphes. 

Charged lepton isolation 

To improve the quality of the contents of the charged lep- 
ton collections, isolation criteria can be applied. This requires 
that electron or muon candidates are isolated in the detector 
from any other particle, within a small cone. In Delphes, 
charged lepton isolation demands by default that there is no 
other charged particle with pr > 2 GeV/c within a cone of 
AR - ^jhrj^ + A(f)^ < 0.5 centered on the cell associated to 
the charged lepton (, obviously taking the magnetic field into 
account. 

The result (i.e. isolated or not) is added to the charged lepton 
measured properties. In addition, the sum Pt of the transverse 
momenta of all tracks but the lepton one within the isolation 
cone is provided [o]: 

tracks 

^7- = ^ Prd) 

No calorimetric isolation is applied, but the charged lepton 
collections contain also the ratio p( between (1) the sum of 
the transverse energies in all calorimetric cells ina N x N grid 
around the lepton, and (2) the lepton transverse momentum [p]: 

'£-Ej(i) 

PC - — , iinN X N grid centred on £. 

Pt(0 



3.2. Jet reconstruction 

A realistic analysis requires a correct treatment of partons 
which have hadronised. Therefore, the most widely currently 
used jet algorithms have been integrated into the Delphes 
framework using the FastFet tools^. Six different jet reconstruc- 
tion schemes are available [8, r]. For all of them, the calori- 
metric cells are used as inputs. Jet algorithms differ in their 
sensitivity to soft particles or collinear splittings, and in their 
computing speed performances. 

Cone algorithms 

1. CDF Jet Clusters [9]: Cone algorithm forming jets by 
combining cells lying within a circle (default radius AR = 
0.7) in the (77, (p) space. Jets are seeded by all cells with 
transverse energy Er above a given threshold (default: 
Et > 1 GeV) [t]. 

2. CDF MidPoint [10]: Cone algorithm with additional "mid- 
points" (energy barycentres) in the list of seeds. 

3. Seedless Infrared Safe Cone [11]: The SISCone algorithm 
is simultaneously insensitive to additional soft particles 
and collinear splittings. 

Recombination algorithms 

The next three jet algorithms rely on recombination schemes 
where calorimeter cell pairs are successively merged: 

4. Longitudinally invariant ki jet [12], 

5. Cambridge/Aachen jet [13], 

6. Anti kf jet [14], where hard jets are exactly circular in the 
{y, (p) plane. 

The recombination algorithms are safe with respect to soft 
radiations {infrared) and collinear splittings. Their implemen- 
tations are similar except for the definition of the distances used 
during the merging procedure. 

By default, reconstruction uses the CDF cone algorithm. Jets 
are stored if their transverse energy is higher than 20 GeV [s]. 

Energy flow 

In jets, several particle can leave their energy into a given 
calorimetric cell, which broadens the jet energy resolution. 
However, the energy of charged particles associated to jets can 
be deduced from their associated track, thus providing a way 
to identify some of the components of cells with multiple hits. 
When the energy flow is switched on in Delphes, the energy of 
tracks pointing to calorimetric cells is subtracted and smeared 
separately, before running the chosen jet reconstruction algo- 
rithm. This option allows a better jet energy reconstruction [u]. 



^ A more detailed description of tlie jet algoritlims is given in the User Man- 
ual, in appendix. 
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3.3. b-tagging 

A jet is tagged as fe-jets if its direction lies in the acceptance 
of the tracker and if it is associated to a parent b-qnaik. The 
(mis)tagging rehes on the identity of the most energetic parton 
within a cone around the jet axis, with a radius equal to the 
one used to reconstruct the jet (default: AR of 0.7). By default, 
a /7-tagging efficiency of 40% is assumed if the jet has a par- 
ent b quark. For c-jets and light jets (i.e. originating in u, d, 
s quarks or in gluons), a fake /7-tagging efficiency of 10% and 
1% is assumed respectively [v]. Therefore, in current version 
of Delphes, the displacement of secondary vertices is not taken 
into account. As such, the Zj-tagging efficiency is below the 
expected 40%. 

3.4. Identification of hadronic t decays 

Jets originating from r-decays are identified using a proce- 
dure consistent with the one applied in a full detector simula- 
tion [5]. The tagging relies on two properties of the r lepton. 
First, 77% of the r hadronic decays contain only one charged 
hadron associated to a few neutrals (l-prong). Secondly, the 
particles arisen from the r lepton produce narrow jets in the 
calorimeter (this is defined as the jet collimation). 




Figure 4: Illustration of the identification of T-jets (l-prong). The jet cone 
is narrow and contains only one track. The small cone serves to apply the 
electromagnetic collimation, while the broader cone is used to reconstruct the 
jet originating from the T-decay. 



Electromagnetic collimation 

To use the narrowness of the r-jet, the electromagnetic col- 
limation Cj is defined as the sum of the energy of cells in a 
small cone of radius R'"^ around the jet axis, divided by the 
energy of the reconstructed jet. To be taken into account, a 
calorimeter cell should have a transverse energy above a 
given threshold. A large fraction of the jet energy is expected 
in this small cone. This fraction, or collimation factor, is repre- 
sented in Fig. 5 for the default values (see Tab. 3). 




Figure 5: Distribution of the electromagnetic collimation Cj variable for true 
T-jets, normalised to unity. This distribution is shown for associated WH pho- 
toproduction [16], where the Higgs boson decays into a W^W" pair. Each W 
boson decays into a Cv( pair, where C = e,p.,r. Events generated with Mad- 
Graph/MadEvent [17]. Final state hadronisation is peiformed by Pythia [18]. 
Histogram entries coirespond to true T-jets, matched with generator-level data. 



Table 3: Default values for parameters used in T-jet reconstruction algorithm. 
Electromagnetic collimation requirements involve the inner small cone radius 
i?*^™, the minimum transverse energy for calorimetric cells and the col- 
limation factor Ct- Tracking isolation constrains the number of tracks with a 
significant transverse momentum p'™'''' in a cone of radius R'™'"^ . Finally, the 
T-jet collection is purified by the application of a cut on the pj of T-jet candi- 
dates [w]. 



Electromagnetic collimation 

7J™ 0.15 
min£^'=" 1.0 GeV 
Cr 0.95 
IVacking isolation 

^tracks 

min pf^"- 2 GeV/c 
T-jet candidate 

vampT lOGeV/c 



Tracking isolation 

The tracking isolation for the r identification requires that the 
number of tracks associated to particles with significant trans- 
verse momenta is one and only one in a cone of radius /;'™ks 
(3-prong T-jets are rejected). This cone should be entirely in- 
corporated into the tracker to be taken into account. Default 
values of these parameters are given in Tab. 3. 

Purity 

Once both electromagnetic collimation and tracking isolation 
are applied, a threshold on the pj of the T-jet candidate is re- 
quested to purify the collection. This procedure selects t lep- 
tons decaying hadronically with a typical efficiency of 66%. 

3.5. Missing transverse energy 

In an ideal detector, momentum conservation imposes the 
transverse momentum of the observed final state /tt"*"* to be 



6 



^ — I — \ — I — \ — I — \ — I — \ — \ — I — \ — 1~ 

MG/ME + Pythia+ Delphes" 



AR < 0.4, p!|:^* > 2 GeV 
Events: WHq'^ WWWq'-j. Illq' 



m^=150 GeV/c^ 




Figure 6: Distribution of the number of tracks A''™'^''* within a small jet cone for 
true T-jets, normalised to unity. Photoproduced WH events, where W bosons 
decay leptonically (e, /i, t), as in Fig. 5. Histogram entries correspond to true 
T-jets, matched with generator-level data. 



equal and in opposite direction to the pr vector sum of the in- 
visible particles, written /77•™"'^ The true missing transverse 
energy, i.e. at generator-level, is calculated as the opposite of 
the vector sum of the transverse momenta of all visible parti- 
cles - or equivalently, to the vector sum of invisible particle 
transverse momenta. In a real experiment, calorimeters mea- 
sure energy and not momentum. Any problem affecting the de- 
tector (dead channels, misalignment, noisy cells, cracks) wors- 
ens directly the measured missing transverse energy Ej"'^^'^- In 
Delphes, MET is based on the calorimetric cells only. Muons 
and neutrinos are therefore not taken into account for its evalu- 
ation: 



cells 



(3) 



However, as muon candidates, tracks and calorimetric cells are 
available in the output file, the missing transverse energy can 
always be reprocessed a posteriori with more specialised algo- 
rithms. 



4. Trigger emulation 

Most of the usual trigger algorithms select events containing 
leptons, jets, and MET with an energy scale above some thresh- 
old. This is often expressed in terms of a cut on the transverse 
momentum of one or several objects of the measured event. 
Logical combinations of several conditions are also possible. 
For instance, a trigger path could select events containing at 
least one jet and one electron such as p^j > 100 GeV/c and 
> 50 GeV/c. 



A trigger emulation is included in Delphes, using a fully 
parametrisable trigger table [x]. When enabled, this trigger is 
applied on analysis-object data. In a real experiment, the online 
selection is often divided into several steps (or levels), corre- 
sponding to the different trigger levels. First-level triggers are 
fast and simple but based only on partial data as not all detec- 
tor front-ends are readable within the decision latency. Higher 
level triggers are more complex, of finer-but-not-final quality 
and based on full detector data. 

Real triggers are thus intrinsically based on reconstructed 
data with a worse resolution than final analysis information. 
On the contrary, the same information is used in Delphes for 
the trigger emulation and for final analyses. 

5. Very forward detector simulation 

Collider experiments often have additional instrumentation 
along the beamline. These extend the rj coverage to higher val- 
ues, for the detection of very forward final-state particles. In 
Delphes, Zero Degree Calorimeters, roman pots and forward 
taggers have been implemented (Fig. 7), similarly as for CMS 
and ATLAS collaborations [5, 6]. 
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Figure 7: Default location of the very forward detectors, including ZDC, RP220 
and FP420 in the LHC beamUne. Incoming (beam 1, red) and outgoing (beam 
2, black) beams on one side of the fifth interaction point (IPS, .v = m on the 
plot). The Zero Degree Calorimeter is located in perfect alignment with the 
beamline axis at the interaction point, at 140 m, where the beam paths are well 
separated. The forward taggers are near-beam detectors located at 220 m and 
420 m. Beamline simulation with Hector [7]. All very forward detectors are 
located symmetrically around the interaction point. 



5.1. Zero Degree Calorimeters 

In direct sight of the interaction point, on both sides of the 
central detector, the Zero Degree Calorimeters (ZDCs) are lo- 
cated at zero angle, i.e. are aligned with the beamline axis at 
the interaction point. They are placed beyond the point where 
the paths of incoming and outgoing beams separate. These al- 
low the measurement of stable neutral particles (y and n) com- 
ing from the interaction point, with large pseudorapidities (e.g. 
|77n,y| > 8.3 in ATLAS and CMS). 

The trajectory of the neutrals observed in the ZDCs is a 
straight line, while charged particles are deflected away from 
their acceptance window by the powerful magnets located in 
front of them. The fact that additional charged particles may 
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Table 4: Default paiameters for the foraard detectors: distance from the inter- 
action point and detector acceptance. The LHC beamhne is assumed around 
the fifth LHC interaction point (IP). For the ZDC, the acceptance depends only 
on the pseudorapidity of the particle, which should be neutral and stable. It is 
expressed in terms of the particle energy (£). All detectors are located on both 
sides of the interaction point. 



Detector Distance Acceptance 

ZDC ±140 m \7]\ > 8.3 for n and y 

RP220 ±220 m £ e [6100; 6880] (GeV) at 2 mm 

FP420 ±420 m Ee [6880; 6980] (GeV) at 4 mm 



enter the ZDC acceptance is neglected in the current versions 
of Delphes. 

The ZDCs have the ability to measure the time-of-flight of 
the particle. This corresponds to the delay t after which the 
particle is observed in the detector, with respect to the bunch 
crossing reference time at the interaction point (fo): 

f = fo + -x -)^-x{s-z), (4) 

where fo is thus the true time coordinate of the vertex from 
which the particle originates, v the particle velocity, s is the 
ZDC distance to the interaction point, z is the longitudinal co- 
ordinate of the vertex, is the particle emission angle. It is 
assumed that the neutral particle observed in the ZDC is highly 
relativistic and very forward. For the time-of-flight measure- 
ment, a Gaussian smearing can be applied according to the de- 
tector resolution (Tab. 5) [g]. 

The ZDCs are composed of an electromagnetic and a 
hadronic sections, for the measurement of photons and neu- 
trons, respectively. The energy of the observed neutral is 
smeared according to Eq. 1 and the corresponding section res- 
olutions (Tab. 5). The ZDC hits do not enter in the calorimeter 
cell list used for reconstruction of jets and missing transverse 
energy. 

Table 5: Default values for the resolution of the zero degree calorimeters. Res- 
olution on energy measurement is parametrised by the stochastic (S), noise (N) 
and constant (C) terms (Eq. 1) [g]. The time-of-flight is smeared according to 
a Gaussian function. 



ZDC, electromagnetic part 


hadronic part 


S (GeV'/-) 0.7 


1.38 


(GeV) 





C 0.08 


0.13 


ZDC, timing resolution 




(T, (S) 





The reconstructed ZDC hits correspond to neutral particles 
with a lifetime long enough to reach these detectors (default: 
CT > 140 m) and very large pseudorapidities (default: |^| > 8.3). 
Photons and neutrons are identified if their energy overpasses a 
given threshold (def. Ey < 20 GeV and E„ < 50 GeV) [q]. 



5.2. Forward taggers 

Forward taggers (called here RP220, for "roman pots at 
220 m" and FP420 for "forward proton taggers at 420 m", as at 
the LHC) are meant for the measurement of particles following 
very closely the beam path. Such devices, also used at HERA 
and Tevatron, are located very far away from the interaction 
point (further than 150 m in the LHC case). 

To be able to reach these detectors, particles must have a 
charge identical to the beam particles, and a momentum very 
close to the nominal value of the beam particules. These tag- 
gers are near-beam detectors located a few millimetres from the 
true beam trajectory and this distance defines their acceptance 
(Tab. 4). For instance, roman pots at 220 m from the IP and 
2 mm from the beam will detect all forward protons with an 
energy between 120 and 900 GeV [7]. In Delphes, extra hits 
coming from the beam-gas events or secondary particles hitting 
the beampipe in front of the detectors are not taken into account. 

While neutral particles propagate along a straight line to the 
ZDC, a dedicated simulation of the transport of charged parti- 
cles is needed for RP220 and FP420. This fast simulation uses 
the Hector software [7], which includes the chromaticity ef- 
fects and the geometrical aperture of the beamline elements of 
any arbitrary collider 

Forward taggers are able to measure the hit positions {x, y) 
and angles (flj, 0,.) in the transverse plane at the location of the 
detector (s meters away from the IP), as well as the time-of- 
flight^ (t). Out of these the particle energy (£) and the mo- 
mentum transfer it underwent during the interaction (q^) can 
be reconstructed at the analysis level (it is not implemented in 
the current versions of Delphes). The time-of-flight measure- 
ment can be smeared with a Gaussian distribution (default value 
cr,-Os) [y]. 

6. Validation 

Delphes performs a fast simulation of a collider experiment. 
Its performances in terms of computing time and data size are 
directly proportional to the number of simulated events and 
on the considered physics process. As an example, 10,000 
ttX events are processed in 110 s on a regular laptop 
and use less than 250 MB of disk space. The quality and vahd- 
ity of the output are assessed by comparing the resolutions on 
the reconstructed data to the expectations of both CMS [5] and 
ATLAS [6] detectors. 

Electrons and muons resolutions in Delphes match by con- 
struction the experiment designs, as the Gaussian smearing of 
their kinematics properties is defined according to the detec- 
tor specifications. Similarly, the ^-tagging efficiency (for real 
/7-jets) and misidentification rates (for fake ^-jets) are taken di- 
rectly from the expected values of the experiment. Unlike these 
simple objects, jets and missing transverse energy should be 
carefully cross-checked. 



^It is worth noting that for both CMS and ATLAS experiments, the taggers 
located at 220 m are not able to measure the time-of-flight, contrary to FP420 
detectors. 
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6.1. Jet resolution 

The majority of interesting processes at the LHC contain jets 
in the final state. The jet resolution obtained using Delphes 
is therefore a crucial point for its validation, both for CMS- 
and ATLAS-like detectors. This validation is based on pp 
gg events produced with MadGraph/MadEvent and hadronised 
using Pythia [17, 18]. 

For a CMS -like detector, a similar procedure as the one ex- 
plained in pubUshed results is applied here. The events were 
arranged in 14 bins of gluon transverse momentum pr- In each 
pT bin, every jet in Delphes is matched to the closest jet of 
generator-level particles, using the spatial separation between 
the two jet axes 



AR = ^(^rec _ j^MCf + (^rec _ ^MCf < 0.25. 



(5) 



The jets made of generator-level particles, here referred as MC 
jets, are obtained by applying the algorithm to all particles con- 
sidered as stable after hadronisation. Jets produced by Delphes 
and satisfying the matching criterion are called hereafter recon- 
structed jets. All jets are computed with the clustering algo- 
rithm (JetCLU) with a cone radius R of 0.7. 

The ratio of the transverse energies of every reconstructed jet 
Ej'^ to its corresponding MC jet E^'^ is calculated in each pj 
bin. The Ej'^ /E^"^ histogram is fitted with a Gaussian distri- 
bution in the interval +2 RMS centred around the mean value. 
The resolution in each pr bin is obtained by the fit mean (x) 
and variance cr^(jc): 



(#)fit 



(pr(0). for all i 



(6) 
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Figure 8: Resolution of the transverse energy of reconstnicted jets E^'^ as a 
function of the transverse energy of the closest jet of generator-level particles 
E^'^ , in a CMS-like detector. The jets events are reconstructed with the JetCLU 
clustering algorithm with a cone radius of 0.7. The maximum separation be- 
tween the reconstnjcted and MC-jets is AR = 0.25. Dotted line is the fit result 
for comparison to the CMS resolution [5], in blue. The pp — » gg dijet events 
have been generated with MadGraph/MadEvent and hadronised with Pythia. 



The resulting jet resolution as a function of E^'~ is shown in 
Fig. 8. This distribution is fitted with a function of the following 
form: 

e c, (7) 



7MC 



■MC 



where a, b and c are the fit parameters. It is then compared to 
the resolution published by the CMS collaboration [5]. The res- 
olution curves from Delphes and CMS are in good agreement. 

Similarly, the jet resolution is evaluated for an ATLAS-like 
detector. The pp ^ gg events are here arranged in 8 adjacent 
bins in pj. A kj reconstruction algorithm with R - 0.6 is cho- 
sen and the maximal matching distance between the MC-jets 
and the reconstructed jets is set to AR - 0.2. The relative en- 
ergy resolution is evaluated in each bin by: 



cr{E) 




J7MC Y 



(8) 



Figure 9 shows a good agreement between the resolution ob- 
tained with Delphes, the result of the fit with Equation 7 and the 
corresponding curve provided by the ATLAS collaboration [6]. 




ATLAS resolution 

Delphes resolution : £^ = lOp e i .1 iP «M 



<0.5 



Events: pp -> ggX 
kj algorithm A R = 0.6 
MG/IVIE + Pythia + Deiphes 



500 



600 700 

e'^'^ [GeV] 



Figure 9: Relative energy resolution of reconstructed jets as a function of the 
energy of the closest jet of generator-level particles E^'~, in an ATLAS-like 
detector. The jets are reconstructed with the kr algorithm with a radius R = 
0.6. The maximal matching distance between MC- and reconstructed jets is 
AR = 0.2. Only central jets are considered (\r]\ < 0.5). Dotted line is the fit 
result for comparison to the ATLAS resolution [6], in blue. The pp — > gg di- 
jet events have been generated with MadGraph/MadEvent and hadronised with 
Pythia. 



6.2. MET resolution 

All major detectors at hadron colliders have been designed 
to be as hermetic as possible in order to detect the presence of 
one or more neutrinos and/or new weakly interacting particles 
through apparent missing transverse energy. The resolution of 
the /ij-""^^ variable, as obtained with Delphes, is then crucial. 

The samples used to study the MET performance are identi- 
cal to those used for the jet validation. It is worth noting that 
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the contribution to £'™^'* from muons is negligible in the studied 
sample. The input samples are divided in five bins of scalar Et 
sums (I^Et). This sum, called total visible transverse energy, is 
defined as the scalar sum of transverse energy in all cells. The 
quality of the MET reconstruction is checked via the resolution 
on its horizontal component Ef"^'^. 

The f""^ resolution is evaluated in the following way. The 
distribution of the difference between f™^^ in Delphes and at 
generator-level is fitted with a Gaussian function in each ("EEt) 
bin. The fit RMS gives the MET resolution in each bin. The 
resulting value is presented in Fig. 10 as a function of the total 
visible transverse energy, for CMS- and ATLAS -like detectors. 
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extra simultaneous pp collision occurring at high-luminosity in 
the same bunch crossing) [5], which compares very well with 
the a - 0.63 obtained with Delphes. Similarly, for an AT- 
LAS-like detector, a value of 0.53 is obtained by Delphes for 
the a parameter, while the experiment expects it in the range 
[0.53 ; 0.57] [6]. 

6.3. T-jet efficiency 

Table 6 lists the reconstruction efficiencies in Delphes for the 
hadronic r-jets from H,Z ^ t^t . The mass of the Higgs bo- 
son is set successively to 140 and 300 GeV/c^. The inclusive 
gauge boson productions {pp — > HX and pp ZX) are per- 
formed with MadGraph/MadEvent and the t lepton decay and 
further hadronisation are handled by Pythia/Tauola. All recon- 
structed T-jets are 1 -prong, and follow the definition described 
in section 3.3, which is very close to an algorithm of the CMS 
experiment [19]. At last, corresponding efficiencies published 
by the CMS and ATLAS experiments are quoted for compar- 
ison. The level of agreement is satisfactory provided possible 
differences due to the event generation chain and the detail of 
reconstruction algorithms. 



Table 6: Reconstraction efficiencies of r-jets in T^r" decays from Z or H 
bosons, in Delphes, CMS and ATLAS experiments [19, 6]. Two scenarios for 
the mass of the Higgs boson are investigated. Events generated with Mad- 
Graph/MadEvent and hadronised with Pythia. The decays of t leptons is han- 
dled by the Tauola version embedded in Pythia. 
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Figure 10: a-(E'^"^) as a function on the scalar sum of all cells (ZEt) for 
pp — * gg events, for a CMS-like detector (top) and an ATLAS-like detector 
(bottom), for di-jet events produced with MadGraph/MadEvent and hadronised 
with Pythia. 



The resolution cr^ of the horizontal component of MET is 
observed to behave like 



cr., = a y/Ej (GeV'^^), 



(9) 



where the a parameter depends on the resolution of the 
calorimeters. 

The MET resolution expected for the CMS detector for sim- 
ilar events is cr^- = (0.6 - 0.7) y/Er GeV'^^ with no pile-up (i.e. 
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7. Visualisation 

When performing an analysis, a visuaUsation tool is useful 
to convey information about the detector layout and the event 
topology in a simple way. The Fast and Realistic OpenGL Dis- 
player FROG [20] has been interfaced in Delphes, allowing an 
easy display of the defined detector configuration [z] . 

Two and three-dimensional representations of the detector 
configuration can be used for communication purposes, as they 
clearly illustrate the geometric coverage of the diff'erent detec- 
tor subsystems. As an example, the generic detector geometry 
assumed in this paper is shown in Fig. 2 and 11. The extensions 
of the central tracking system, the central calorimeters and both 
forward calorimeters are visible. Note that only the geometri- 
cal coverage is depicted and that the calorimeter segmentation 
is not taken into account in the drawing of the detector 

Deeper understanding of interesting physics processes is pos- 
sible by displaying the events themselves. The visibility of each 
set of objects {e^^, fr^, t=^, jets, transverse missing energy) is en- 
hanced by a colour coding. Moreover, kinematics information 



10 




Figure 11: Layout of the generic detector geometry assumed in Delphes. Open 
3D-view of the detector with solid volumes. Same colour codes as for Fig. 2 
are applied. Additional forward detectors are not depicted. 



of each object is visible by a simple mouse action. As an il- 
lustration, an associated photoproduction of a W boson and a t 
quark [21] is shown in Fig. 12. 




Figure 12: Example oi pp{yp — > Wt)pY event display in side (left) and trans- 
verse (right) views, with t — > Wb. One W boson decays into a /iv^ pair and the 
second one into a ev^ pair. The surviving proton leaves a forward hemisphere 
with no hadronic activity. The isolated muon is shown as the dark blue vector 
Around the electron, in red, is reconstructed a fake r-jet (blue cone suiTounding 
a green arrow). The reconstructed missing energy is visible in grey. 



For comparison. Fig. 13 depicts an inclusive gluon pair pro- 
duction pp — » ggX. The event final state contains more jets, in 
particular along the beam axis, which is expected as the inter- 
acting protons are destroyed by the collision. 




Figure 13: Example of inclusive gluon pair production pp — » ggX. Many jets 
are present in the event, in particular along the beam axis (black line). 



8. Conclusion and perspectives 

We have described here the major features of the Delphes 
framework, introduced for the fast simulation of a collider ex- 
periment. This framework is a tool meant for feasibility studies 
in phenomenology, gauging the observability of model predic- 
tions in collider experiments. 

Delphes takes as an input the output of event-generators and 
yields analysis-object data in the form of TTree in a * . root 
file. The simulation includes central and forward detectors to 
produce realistic observables using standard reconstruction al- 
gorithms. Moreover, the framework allows trigger emulation 
and 3D event visualisation. 

Delphes has been developed using the parameters of the 
CMS experiment but can be easily extended to ATLAS and 
other non-LHC experiments, as at Tevatron or at the ILC. Fur- 
ther developments include a more flexible design for the sub- 
detector assembly, a better b-tag description and possibly the 
implementation of an event mixing module for pile-up event 
simulation. This framework has already been used for several 
analyses [21, 22, 23], in particular in photon-induced interac- 
tions at the LHC. 
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Internal code references 

[a] The standard Monte Carlo event structures StdHEP [25] and HepMC [26] 
can be used as an input. Besides, Delphes can also provide de- 
tector response for events read in "Les Houches Event Format" 
(LHEF [27]) and *.root files obtained from *.hbook using the 
h2root utility from the ROOT framework [3]. See the follow- 
ing classes: HEPEVTConverter, HepMCConverter, LHEFConverter, 
STDHEPConverter and DelphesRootConverter. 

[b] The ROOT output files are created using the ExRootAnalysis utility [4]. 
Generator-level data are located under the GEN tree, the analysis data ob- 
jects after reconstruction under the Analysis tree, and the results of the 
trigger emulation under the Trigger tree. 

[c] Set the FLAG_LHCO variable to 1 or in the detector card to switch on/off 
the creation of * . Ihco output file. 

[d] The list of particles considered as invisible is accessible in the 
PdgParticle class. This list currently contains the PIDs 12, 14, 16, 
1000022, 1000023, 1000025, 1000035 and 1000045, in absolute values. 

[e] The detector card is the data/DetectorCard . dat file. This file is parsed 
by the SmearUtil class. 

[f] Detector and tiigger cards for the ATLAS and CMS experiments are also 
provided in data/ directory. 

[g] The resolution terms in the detector card are named ELG_Xyyy or 
HAD_Xyyy, refering to electromagnetic and hadronic terms (resp.); X is re- 
placed by S, N, C for the stochastic, noise and constant terms; and finally 
yyy is cen for central part, ec for end-caps, f wd for the forward calorime- 
ters and zdc for the zero-degree calorimeters. 

[h] See the TrackPropagat ion class. 

[i] See the TRACK.ef f and TRACK.ptmin terms in the detector card. 

[j] The response of the detector is applied to the electromagnetic and the 
hadronic particles through the SmearElectron and SmearHadron meth- 
ods in the SmearUtil class. 

[k] To implement different ratios for other particles, see the BlockClasses 
class. 

[1] As the detector is assumed to be cylindrical (e.g. symmetric in </> and with 
respect to the t] = plane), the detector card stores the number of calori- 
metric cells with = and r; > (default: 40 cells). For a given t], 
the size of the </> segmentation is also specified. See the TOWER_nuinber, 
TOWER_eta_edges and TQWER_dphi variables in the detector card. 

[m] All these processed data are located under the Analysis tree. 

[n] See the SmearMuon method in the SmearUtil class. 

[o] See the IsolFlag and IsolPt values in the Electron or Muon collec- 
tions in the Analysis tree, as well as the ISOL_PT and ISQL_Cone vari- 
ables in the detector card. 

[p] Calorimetric isolation parameters in the detector card are ISOL_Calo_ET 
and lSOL_Calo_Grid in the detector card. 

[q] These thresholds are defined by the ZDC_gaimna_E and ZDC_n_E variables 
in the detector card. 

[r] The choice is done by allocating the JET_jetalgo input parameter in the 
detector card. 

[s] See the PTCUT_j et variable in the detector card. 

[t] See the JET_coneradius and JET_seed variables in the detector card. 
The existing FastJet code has been modified to allow easy modification of 
the cell pattern in (;;, ip) space. In following versions of Delphes, a new 
dedicated plug-in will be created on this purpose. 



[u] Set JET_Ef low to 1 or in the detector card in order to switch on or off the 
energy flow for jet reconstruction. 

[v] Corresponding to the BTAG.b, BTAG_mistag_c and BTAG_mistag_l con- 
stants, for the efficiency of tagging of a 6-jet, the efficiency of mistagging 
a f-jet as a fe-jet, and the efficiency of mistagging a light jet {u,d,s,g) as a 
fc-jet. 

[w] See the following parameters in the detector card: 

TAU_energy_scone for R™; JET_M_seed for min E^^"; 

TAU_energy_frac for Cj, TAU_track_scone forR'™*"*; PTAU_track_pt 

for min p^"'^^'^ and TAUJET.pt for min pT- 
[x] The trigger card is the dat a/Trigger Card, dat file. Default trigger files 

are also available for CMS-like and ATLAS-hke detectors 
[y] The resolution is defined by the RP220_T_resolution and 

RP420_T_resolution parameters in the detector card, 
[z] To prepare the visualisation, the FLAG_FRQG parameter should be equal to 

1. 
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A. User manual 

The available C++-code is compressed in a zipped tar file which contains everything needed to run the Delphes package, assuming 
a running ROOT installation. The package includes ExRootAnalysis [4], Hector [7], FastJet [8], and FROG [20], as well as the 
conversion codes to read standard StdHEP input files (mcf io and stdhep) [24] and HepMC [26]. In order to visualise the events 
with the FROG software, a few additional external libraries may be required, as explained in http://projects.hepforge.org/FROG/. 

A.l. Getting started 

In order to run Delphes on your system, first download its sources and compile them: 

wget http : //www . f ynu.ucl . ac .be/users/ s . ovyn/Delphes/f iles/Delphes_V_* . tar . gz 

Replace the * symbol by the proper version number Always refer to the download page on the Delphes website 
http://www.fynu.ucl.ac.be/users/s.ovyn/Delphes/download.html. Current version of Delphes for this manual is V 1.8 (July 2009). 

meOmylaptop : ~$ tar -xvf Delphes_V_* . tar . gz 
meOmylaptop : ~$ cd Delphes_V_* . * 
meOmylaptop : ~$ ./genMakef ile.tcl > Makefile 
meOmylaptop : ~$ make 

Due to the large number of external utilities, the number of printed lines during the compilation can be high. The user should 
not pay attention to possible warning messages, which are due to the external packages used by Delphes. When compilation is 
completed, the following message is printed: 

meSmylaptop : ~$ Delphes has been compiled 
meOmylaptop : ~$ Ready to run 

A.l. Running Delphes on your events 

In this sub-appendix, we will explain how to use Delphes to perform a fast simulation of a general-purpose detector on your event 
files. The first step to use Delphes is to create the list of input event files (e.g. inputlist . list). It is important to notice that all 
the files comprised in the list file should have the same of extension (* . hep, * . Ihe, * . hepmc or * . root). In the simplest way to 
run Delphes, you need this input file and you need to specify the name of the output file that will contain the generator-level data 
(GEN tree), the analysis data objects after reconstruction (Analysis tree), and the results of the trigger emulation (Trigger tree). 

meOmylaptop : ~$ ./Delphes inputlist . list OutputRootFileName.root 

A.2.1. Setting up the configuration 

The program is driven by two datacards (default cards are data/DetectorCard.dat and data/Tr iggerCard.dat) which 
allow the user to choose among a large spectrum of running conditions. Please note that if the user does not provide these datacards, 
the running will be done using the default parameters defined in the constructor of the class RESOLution (see next). If you choose a 
different detector or running configuration, you will need to edit the datacards accordingly. Detector and trigger cards are provided 
in the data/ subdirectory for the CMS and ATLAS experiments. 

1 . The detector card It contains all pieces of information needed to run Delphes: 

• detector parameters, including calorimeter and tracking coverage and resolutions, transverse energy thresholds for object 
reconstruction and jet algorithm parameters. 

• six flags (FLAG_bf ield, FLAG_vf d, FLAG_RP, FLAG_trigger, FLAG_FROG and FLAG_LHCO), should be set in order 
to configure the magnetic field propagation, the very forward detectors simulation, the use of very forward taggers, the 
trigger selection, the preparation for FROG display and the creation of an output file in * . LHCO text format (respectively). 

If no datacard is provided by the user, the default smearing and running parameters are used (corresponding to tables 1, 2). 
Definition of the sub-detector extensions: 



CEN_max_tracker 
CEN_max_calo_cen 
CEN_max_calo_ec 
CEN_max_calo_f wd 
CEN_max_mu 



2.5 
1.7 
3.0 
5.0 
2.4 



/ / Maximum tracker coverage 

// central calorimeter coverage 

// calorimeter endcap coverage 

// forward calorimeter pseudorapidity coverage 

// muon cheunbers pseudorapidity coverage 
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Definition of the sub-detector resolutions: 



# Energy resolution for electron/photon in central/endcap/f wd/zdc calos 



# \sigma/E = 


C + N/E + S/\sqrt{E>, E 


in GeV 


ELG 


S cen 


. 


05 


II 


g 


"t erm 


for 


rpntral FPAT 


rji_ivj_ 


_Ncen 






/ / 


AT 


"t erm 






ELG. 


_Ccen 


0. 


.005 


II 


c 


term 






ELG. 


.Sec 


0. 


.05 


II 


s 


term 


for 


ECAL endcap 


ELG. 


.Nec 


0. 


.25 


II 


N 


term 






ELG. 


.Cec 


0. 


.005 


II 


c 


term 






ELG. 


.Sfwd 


2. 


.084 


II 


s 


term 


for 


FCAL 


ELG. 


.Nfwd 


0. 




II 


N 


term 






ELG. 


.Cfwd 


0. 


.107 


II 


c 


term 






ELG. 


.Szdc 


0. 


.70 


II 


s 


term 


for 


ZDC 


ELG. 


.Nzdc 


0. 




II 


N 


term 






ELG. 


.Czdc 


0. 


.08 


II 


c 


term 







# Energy resolution for hadrons in central/endcap/f wd/zdc calos 

# \sigma/E = C + N/E + S/\sqrt{E>, E in GeV 



HAD. 


.Seen 


1. 


.5 


// 


S 


term 


for 


central HCAL 


HAD. 


.Ncen 


0, 




// 


N 


term 






HAD. 


.Ccen 


0, 


,05 


// 


C 


term 






HAD. 


.Sec 


1. 


.5 


// 


S 


term 


for 


HCAL endcap 


HAD. 


.Nec 


0, 




// 


N 


term 






HAD. 


.Cec 


0, 


.05 


// 


C 


term 






HAD. 


.Sfwd 


2. 


.7 


// 


S 


term 


for 


FCAL 


HAD. 


.Nfwd 


0, 




// 


N 


term 






HAD. 


.Cfwd 


0, 


.13 


// 


C 


term 






HAD. 


.Szdc 


1. 


.38 


// 


S 


term 


for 


ZDC 


HAD. 


.Nzdc 


0, 




// 


N 


term 






HAD. 


.Czdc 


0, 


.13 


// 


C 


term 







# Time resolution for ZDC/RP220/RP420 
ZDC_T_resolution // in s 

RP220_T_resolution // in s 

RP420_T_resolution // in s 



# Muon smearing 
MU Smear Pt 



0.01 



// trsinsverse momentum Pt in GeV/c 



# Tracking efficiencies 
TRACK_ptmin . 9 

TRACK_eff 90 



/ / minimal pT 

// efficiency associated to the tracking C"/,) 



Definitions related to the calorimetric cells: 

# Calorimetric towers 
TOWER_number 40 

TOWER_eta_edges 0. 0.087 0.174 0.261 0.348 0.435 0.522 0.609 0.696 0.783 

0.870 0.957 1.044 1.131 1.218 1.305 1.392 1.479 1.566 1.653 
1.740 1.830 1.930 2.043 2.172 2.322 2.500 2.650 2.868 2.950 
3.125 3.300 3.475 3.650 3.825 4.000 4.175 4.350 4.525 4.700 
5.000 



TOWER_dphi 5555555555555555555 10 

10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 10 20 20 

TOWER_eta_edges is the list of the edges in r\ of all cells, in the 77 > hemisphere (the detector is supposed to be symmetric 
with respect to the 77 = plane, as well as around the z-axis). Starts with the lower edge of the most central tower (default: 
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t; = 0) and ends with the higher edge of the most forward tower TOWER_dphi lists the tower size in (in degree), assuming 
that all cells are similar in for a given rj. 

Thresholds applied for storing the reconstructed objects in the final collections: 

# Thresholds for reconstructed objects, in GeV/c 
PTCUT_elec 10.0 

PTCUT_muon 10.0 

PTCUT_jet 20.0 

PTCUT_gainma 10 . 

PTCUT_taujet 10.0 

# Thresholds for reconstructed objects in ZDC, E in GeV 
ZDC_gamma_E 20 

ZDC_n_E 50 

Definitions of variables related to the charged lepton isolation: 



# Charged 


lepton 


isolation. Pt and Et in GeV 


ISOL. 


.PT 




2, 


,0 


//minimal pt of tracks for isolation criteria 


ISOL. 


.Cone 




0, 


.5 


//Cone for isolation criteria 


ISOL. 


.Calo. 


.Cone 


0, 


,4 


//Cone for calorimetric isolation 


ISOL. 


.Calo. 


.ET 


2, 


.0 


//minimal tower E_T for isolation criteria. 1E99 means "off 


ISOL. 


.Calo. 


.Grid 


3 




//Grid size (N x N) for calorimetric isolation 



Definitions of variables related to the jet reconstruction: 

# General jet variable 

JET_coneradius 0.7 // generic jet radius 
JET_jetalgo 1 //I for Cone algorithm, 

// 2 for MidPoint algorithm, 

// 3 for SIScone algorithm, 

// 4 for kt algorithm 

// 5 for Cambridge/Aachen algorithm 

// 6 for anti-kt algorithm 
JET_seed 1.0 // minimum seed to start jet reconstruction, in GeV 

JET_Eflow 1 // Energy flow: perfect energy assumed in the tracker coverage. 

// 1 is 'on' ; is 'off 

# Tagging definition 

BTAG_b 40 // b-tag efficiency (7.) 

BTAG_mistag_c 10 // mistagging (7.) 
BTAG_mistag_l 1 // mistagging (7.) 

Switches for options 

# FLAGS 

FLAG_bfield 1 //I to run the bfield propagation else 

FLAG_vfd 1 //I to run the very forward detectors else 

FLAG_RP 1 //I to run the very forward detectors else 

FLAG_trigger 1 //I to run the trigger selection else 

FLAG_FROG 1 //I to run the FROG event display 

FLAG_LHCO 1 //I to run the LHCO 

Parameters for the magnetic field simulation: 



# In case BField 


propagation allowed 




TRACK. 


.radius 




129 


// 


radius of the BField coverage. 


, in cm 


TRACK. 


.length 




300 


// 


length of the BField coverage. 


, in cm 


TRACK. 


.bfield. 


.X 





// 


X component of the BField, in 


T 


TRACK. 


.bfield. 


-y 





// 


Y component of the BField, in 


T 


TRACK. 


.bfield. 


.z 


3.8 


// 


Z component of the BField, in 


T 
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Parameters related to the very forward detectors 



# Very forward detector extension, in pseudorapidity 

# if allowed 

VFD_min_zdc 8.3 // Zero-Degree neutral Calorimeter 

VFD_s_zdc 140 // distance of the ZDC, from the IP, in [m] 

#\textit{Hector} parameters 



RP. 


.220_s 


220 


// 


distance of the RP to the IP, in meters 


RP. 


.220_x 


0.002 


// 


distance of the RP to the beam, in meters 


RP. 


.420_s 


420 


// 


distance of the RP to the IP, in meters 


RP. 


.420_x 


0.004 


// 


distance of the RP to the beam, in meters 


RP. 


.beamlCard 


data/LHCBlIR5_v6.500.tfs // beam optics file, beam 1 


RP. 


.beain2Card 


data/LHCB21R5_v6.500.tfs // beam optics file, beam 2 


RP. 


.IP_naine 


IP5 


// 


tag for IP in \textit{Hector} ; 'IPl' for ATLAS 


RP. 


.of f setEl_x 


0.097 


// 


horizontal separation between both beam, in meters 


RP. 


.of f setEl_y 





// 


vertical separation between both beam, in meters 


RP. 


.of f setEl_s 


120 


// 


distcince of beam separation point, from IP 


RP. 


.cross_x 


-500 


// 


IP offset in horizontal plane, in micrometers 


RP. 


.cross_y 





// 


IP offset in vertical plane, in micrometers 


RP. 


.cross_ang_x 


142.5 


// 


half -crossing angle in horizontal plane, in microrad 


RP. 


.cross_ajig_y 





// 


half -crossing angle in vertical plane, in microrad 



Others parameters: 

# In case FROG event display allowed 
NEvents_FRQG 100 

# Number of events to process 

NEvents -1 // -1 means 'all' 

# input PDG tables 

PdgTableFilencune data/particle . tbl // table with particle pid, mass , charge ,.. . 

In general, energies, momenta and masses are expressed in GeV, GeV/c, GeV/c^ respectively, and magnetic fields in T. 
Geometrical extension are often referred in terms of pseudorapidity rj, as the detectors are supposed to be symmetric in (p. 
From version 1.8 onwards, the number of events to run is also be included in the detector card (NEvents). For version 1.7 
and earlier, the parameters related to the calorimeter endcaps (CEN_max_calo_ec, ELG_Sec, ELGJJec, ELG_Cec, HAD_Sec, 
HADJJec and HAD_Cec) did not exist in the detector cards; in addition, some other variables had different names (HAD_Scen 
was HAD_Sf cal, HAD_Ncen was HADJJf cal, HAD_Ccen was HAD_Cf cal, HAD_Sf wd was HAD_Shf , HADJJfwd was HADJJhf , 
HAD_Cf wd was HAD_Chf ). However, these cards are still completely compatible with new versions of Delphes. In such a 
case, the calorimeter endcaps are simply assumed to be located at the edge of the central calorimeter volumes, with the same 
resolution values. 

2. The trigger card 

This card contains the definitions of all trigger-bits. Cuts can be applied on the transverse momentum pj of electrons, muons, 
jets, T-jets, photons and the missing transverse energy. The following codes should be used so that Delphes can correctly 
translate the input list of trigger-bits into selection algorithms: 



Trigger code 


Corresponding object 


ELEC_PT 


electron 


IElec_PT 


isolated electron 


MUON_PT 


muon 


IMuon_PT 


isolated muon 


JET_PT 


jet 


TAU_PT 


T-jet 


ETMIS_PT 


missing transverse energy 


GAMMA_PT 


photon 


Bjet_PT 


^-jet 
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Each line in the trigger datacard is allocated to exactly one trigger-bit and starts with the name of the corresponding trigger. 
Logical combination of several conditions is also possible. If the trigger-bit requires the presence of multiple identical objects, 
the order of their pj thresholds is very important: they must be defined in decreasing order The transverse momentum pj is 
expressed in GeV/c. Finally, the different requirements on the objects must be separated by a && flag. The default trigger card 
can be found in the data repository of Delphes (data/TriggerCard . dat), as well as for both CMS and ATLAS experiments 
at the LHC. An example of trigger table consistent with the previous rules is given here: 

Single Jet » JET_PT: '200' 

DoubleElec » ELEC_PT: '20' kk ELEC_PT: '10' 

SingleElec and Single Muon » ELEC_PT: '20' && MUON_PT: '15' 

A.2.2. Running the code 

First, create the detector and trigger cards (data/DetectorCard . dat and data/Tr iggerCard . dat). 
Then, create a text file containing the list of input files that will be used by Delphes (with extension * . Ihe, * . hepmc, * . root or 
* . hep). To run the code, type the following command (in one line) 

meSmylaptop : ~$ ./Delphes inputlist . list OutputRootFileName . root 

data/DetectorCard . dat data/TriggerCard . dat 

As a reminder, typing the . /Delphes command simply displays the correct usage: 

meSmylaptop : ~$ ./Delphes 
Usage: ./Delphes input_file output_file [detector_card] [trigger_card] 
input_list - list of files in Ntpl, StdHep, HepMC or LHEF format, 
output_file - output file. 

detector_card - Card containing resolution variables for detector simulation (optional) 
trigger_card - Card containing the trigger algorithms (optional) 

A.3. Getting the Delphes information 
A.3.1. Contents of the Delphes ROOT trees 

The Delphes output file (* . root) is subdivided into three trees, corresponding to generator-level data, analysis-object data and 
trigger output. These trees are structures that organise the output data into branches containing data (or leaves) related with each 
others, like the kinematics properties (£, p^, 77, . . .) of a given particle. 

Here is the exhaustive list of branches availables in these trees, together with their corresponding physical objet and 
ExRoot Analysis C++ class name: 



GEN Tree 
Particle 



generator particles from hepevt 



GenP article 



Trigger Tree 
TrigResult 



Acceptance of diff'erent trigger-bits 



TRootTriKKer 



Analysis Tree 

Tracks Collection of tracks 

CaloTower Calorimetric cells 

Electron Collection of electrons 

Photon Collection of photons 

Muon Collection of muons 

Jet Collection of jets 

TauJet Collection of jets tagged as r-jets 

ETmis Transverse missing energy information 

ZDChits Hits in the Zero Degree Calorimeters 

RP220hits Hits in the first proton taggers 

FP420hits Hits in the next proton taggers 



TRootTracks 

TRootCalo 

TRootElectron 

TRootPhoton 

TRootMuon 

TRoot Jet 

TRootTauJet 

TRootETmis 

TRootZdcHits 

TRootRomanPotHits 

TRootRomanPotHits 



The third column shows the names of the corresponding classes to be written in a ROOT tree. The bin number in the unique leaf in 
the trigger tree (namely, TrigResult .Accepted) corresponds to the trigger number in the provided list. In addition, the result 
of the global trigger decision upon each event (i.e. the logical OR of all trigger conditions) is stored in the first bin (number 0) of this 
leaf. In Analysis tree, all classes except TRootTracks, TRootCalo, TRootTrigger, TRootETmis and TRootRomanPotHits 
inherit from the class TRootParticle which includes the following data members (stored as leaves in branches of the trees): 
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Most common leaves 

float E; // particle energy in GeV 

float Px; // particle momentum vector (x component) in GeV/c 

float Py; // particle momentum vector (y component) in GeV/c 

float Pz; // particle momentum vector (z component) in GeV/c 

float PT; // particle transverse momentum in GeV/c 

float Eta; // particle pseudorapidity 

float Phi; // particle azimuthal angle in rad 



In addition to their kinematics, some additional properties are available for specific objects: 



Leaves in the Particle branch (GEN tree) 



int PID; 


// 


particle 


HEP ID number 








int Status; 


// 


particle 


status 








int Ml; 




// 


particle 


1st mother 








int M2; 




// 


particle 


2nd mother 








int Dl; 




// 


particle 


1st daughter 








int D2; 




// 


particle 


2nd daughter 








float Charge; 


// 


electrical charge in units of e 






float T 




// 


particle 


vertex position 


(t component, 


in 


mm/c) 


float X 




// 


particle 


vertex position 


(x component, 


in 


mm) 


float Y 




// 


particle 


vertex position 


(y component. 


in 


mm) 


float Z 




// 


particle 


vertex position 


(z component. 


in 


mm) 


float M 




// 


particle 


mass in GeV/c^ 









Additional leaves in Electron and Muon branches (Analysis tree) 

int Charge // particle Charge 

bool IsolFlag // stores the result of the tracking isolation test 

float IsolPt // sum of all track pt in isolation cone (GeV/c) 

float EtaCalo // particle pseudorapidity when entering the calo 

float PhiCalo // particle azimuthal angle in rad when entering the calo 

float EHoverEE // hadronic energy over electromagnetic energy 

float EtRatio // calo Et in NxN-cell grid around the muon over the muon Et 



Additional leaf in the Jet branch (Analysis tree) 

bool Btag // stores the result of the b-tagging 

int NTracks // number of tracks associated to the jet 

float EHoverEE // hadronic energy over electromagnetic energy 



Leaves in the Tracks branch (Analysis tree) 



float 


Eta 


// 


pseudorapidity at the beginning of the 


track 


float 


Phi 


// 


azimuthal cingle at the beginning of the track 


float 


EtaOuter 


// 


pseudorapidity at the end of the track 




float 


PhiOuter 


// 


azimuthal angle at the end of the track 


float 


PT 


// 


track transverse momentum in GeV/c 




float 


E 


// 


track energy in GeV 




float 


Px 


// 


track momentum vector (x component) in 


GeV/c 


float 


Py 


// 


track momentum vector (y component) in 


GeV/c 


float 


Pz 


// 


track momentum vector (z component) in 


GeV/c 


float 


Charge 


// 


track charge in units of e 
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Leaves in the CaloTower branch (Analysis tree) 

float Eta // pseudorapidity of the cell 

float Phi // azimuthal angle of the cell in rad 

float E // cell energy in GeV 

float E_em // electromagnetic component of the cell energy in GeV 

float E_had // hadronic component of the cell energy in GeV 

float ET // cell transverse energy in GeV 

Leaves in the ETmis branch (Analysis tree) 

float Phi // azimuthal angle of the transverse missing energy in rad 

float ET // transverse missing energy in GeV 

float Px // X component of the transverse missing energy in GeV 

float Py // y component of the transverse missing energy in GeV 

The hits in very forward detector (ZDC, RP220, FP420) have some common data. In particular, the side variable tells in which 
detector (left:-l or right:+l of the interaction point) the hit has been seen. Moreover, some generator level data is provided for 
information, as the correspondance with the contents of the GEN tree is not possible. These generator-level data correspond to the 
particle kinematics (energy, momentum, angle) and identification (pid). 

Conunon leaves for ZDC, RP220, FP420 



float T 


// 


time of flight in s 






float E 


// 


measured/smeared energy in GeV 






int side 


// 


-1 or +1 






Generator level data 










int pid; 


// 


particle ID 






float genPx; 


// 


particle momentum vector (x component) 


in 


GeV/c 


float genPy; 


// 


particle momentum vector (y component) 


in 


GeV/c 


float genPz; 


// 


particle momentum vector (z component) 


in 


GeV/c 


float genPT; 


// 


particle transverse momentum in GeV/c 






float genEta; 


// 


particle pseudorapidity 






float genPhi ; 


// 


particle azimuthal angle in rad 







Additional leaves in the ZDChits branch (Analysis tree) 

int hadronicJiit // 0(is not hadronic) or l(is hadronic) 

Additional leaves in the RP220hits and FP420hits branches (Analysis tree) 

flaot S // detector position from IP in m 

float X // hit horizontal position in m 

float Y // hit vertical position in m 

float TX // hit horizontal angle in rad 

float TY // hit vertical angle in rad 

float q2 // reconstructed momentum transfer in GeV^ 

The hit position is computed from the center of the beam position, not from the edge of the detector. 

A.4. Deeper description of jet algorithms 

In this section, we briefly describe the differences between the six jet algorithms interfaced in Delphes, via the FastJet utiliy [8]. 
Jet algorithms differ in their sensitivity to soft particles or collinear splittings, and in their computing speed performances. The 
first three belong to the cone algorithm class while the last three are using a sequential recombination scheme. For all of them, the 
calorimetric cells are used as inputs for the jet clustering. 

Cone algorithms 

1 . CDF Jet Clusters [9] : Basic cone reconstruction algorithm used by the CDF experiment in Run II). All cells lying in a circular 
cone around the jet axis with a transverse energy Ej higher than a given threshold are used to seed the jet candidates. This 
algorithm is fast but sensitive to both soft particles and collinear splittings. 

2. CDF MidPoint [10]: Cone reconstruction algorithm developed for the CDF Run II to reduce infrared and collinear sensitivities 
compared to purely seed-based cone by adding 'midpoints' (energy barycentres) in the list of cone seeds. 

3. Seedless Infrared Safe Cone [11]: The SISCone algorithm is simultaneously insensitive to additional soft particles and collinear 
splittings, and fast enough to be used in experimental analysis. 
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Recombination algorithms 

The three sequential recombination jet algorithms are safe with respect to soft radiations (infrared) and collinear splittings. They 
rely on recombination schemes where calorimeter cell pairs are successively merged. The definitions of the jet algorithms are 
similar except for the definition of the distances d used during the merging procedure. Two such variables are defined; the distance 
dij between each pair of cells (i, j), and a variable c/,b (beam distance) depending on the transverse momentum of the cell /. The 
jet reconstruction algorithm browses the calorimetric cell list. It starts by finding the minimum value d^nin of all the distances 
djj and dis- If t/min is a dij, the cells / and j are merged into a single cell with a four-momentum p'' - p^(i) + p^( j) (E-scheme 
recombination). If d^m is a djs, the cell is declared as a final jet and is removed from the input list. This procedure is repeated until 
no cells are left in the input list. Further information on these jet algorithms is given here below, using k,i, y, and 0, as the transverse 
momentum, rapidity and azimuth of calorimetric cell / and hRij — ^j(yi - yj)- + (cpi - 0^)^ as the jet-radius parameter: 

4. Longitudinally invariant k, jet [12], with dij - min(A:p;., kfj) x and diB - kfj, 

AR- 

5. Cambridge/Aachen jet [13], with dij — and diB — 1, 

6. Anti k, jet [14], where hard jets are exactly circular in the (y, cf>) plane: dij - min(l /kj^, l/kfj) x and diB - p- 

A. 5. Running an analysis on your Delphes events 

To analyse the ROOT ntuple produced by Delphes, the simplest way is to use the Analysis_Ex . cpp code which is coming in 
the Examples repository of Delphes. Note that all of this is optional and done to facilitate the analyses, as the output from Delphes 
is viewable with the standard ROOT TBrowser and can be analysed using the MakeClass facility. As an example, here is a simple 
overview of a myoutput . root file created by Delphes: 

meSmylaptop : ~$ root -1 myoutput . root 
root [0] 

Attaching file myoutput . root as _fileO... 
root [1] .Is 

TFile** myoutput . root 

TFile* myoutput . root 

KEY: TTree GEN;1 Analysis tree 

KEY: TTree Analysis;! Analysis tree 

KEY: TTree Trigger;! Analysis tree 

root [2] TBrowser t; 
root [3] Analysis->GetEntries 
(const Long64_t)200 

root [4] GEN->GetListOfBranches()->ls() 



OBJ 
OBJ 
OBJ 
OBJ 



TBranchElement Event Event_ : at : 0x9!08f30 

TBranctL Event_size Event_size/I : at : 0x910cfd0 

TBranchElement Particle Particle_ : at : 0x9!0c6b0 
TBranch Particle_size Particle_size/1 : at : 0x9111c58 



root [5] Trigger->GetListOfLeaves()->ls() 



OBJ 
OBJ 
OBJ 



TLeaf Element TrigResult_ TrigResult_ : at : 0x90f90a0 

TLeaf Element TrigResult . Accepted Accepted [TrigResult_] : at : 0x90f9000 

TLeaf I TrigResult_size TrigResult_size : at : 0x90fb860 



The . Is command lists the current keys available and in particular the three tree names. TBrowser t launches a browser and the 
GetEntries method outputs the number of data in the corresponding tree. The list of branches or leaves can be displayed with 
the GetListOf Branches and GetListOf Leaves () methods, pointing to the ls() one. In particular, it is possible to shown 
only parts of the output, using wildcard characters (*): 

root [6] Analysis->GetListOfLeaves()->ls("*.E") 



OBJ 


TLeaf Element 


Jet.E 




E[Jet_] : 


at: 


0xa08bc68 


OBJ 


TLeaf Element 


TauJet 


E 


E[TauJet_] : 





at: 0xal48910 


OBJ 


TLeaf Element 


Electron. E 


E [Electron_] 




at: 0xald8a50 


OBJ 


TLeaf Element 


Muon . E 




E[Muon_] : 


at 


: 0xa28ac80 


OBJ 


TLeaf Element 


Photon 


E 


E[Photon_] : 





at: Oxa33cd88 


OBJ 


TLeaf Element 


Tracks 


E 


E[Tracks_] : 





at : 0xa3cced0 



20 



OBJ 
OBJ 
OBJ 
OBJ 



TLeaf Element 
TLeaf Element 
TLeaf Element 
TLeaf Element 



CaloTower . E 
ZDChits.E 



E [CaloTower_] 
E[ZDChits_] : 



: at: 0xa4bal88 
at: 0xa54a3c8 



RP220hits.E 
FP420hits.E 



E[RP2201iits_] 
E[FP420hits_] 



: at: 0xa61e648 
: at: 0xa6d0920 



To draw a particular leaf, either double-click on the corresponding name in the TBrowser or use the Draw method of the 
corresponding tree. 

root [7] Trigger->Draw("TrigResult. Accepted") ; 

Mathematical operations on several leaves are possible within a given tree, following the C++ syntax: 

root [8] Analysis->Draw("Muon.Px * Muon.Px"); 

root [9] Analysis->Draw("sqrt(pow(Muon.E,2) - pow(Muon.Pz,2) + pow(Muon.PT,2)) ") ; 

Finally, to prepare an deeper analysis, the MakeClass method is useful. It creates two files and *.C) with automatically 
generated code that allows the access to all branches and leaves of the corresponding tree: 

root [10] Trigger->MakeClass() 

Info in <TTreePlayer : : MakeClass> : Files: Trigger. h and 
Trigger. C generated from TTree: Trigger 

For more information, refer to ROOT documentation. Moreover, an example of code (based on the output of MakeClass) is 
provided in the Examiples/ directory. 

To run the Excimples/ Analysis_Ex . cpp code, the two following arguments are required: a text file containing the input Delphes 
root files to run, and the name of the output root file. 

meOmylaptop : ~$ . /Analysis_Ex input_f ile . list output_f ile . root 

One can easily edit, modify and compile (make) changes in this file. 

A.5.1. Adding the trigger information 

The Examples/Trigger JDnly . cpp code permits to run the trigger selection separately from the general detector simulation on 
output Delphes root files. A Delphes root file is mandatory as an input argument for the Trigger_Only routine. The new tree 
containing the trigger result data will be appended to this file. The trigger datacard is also necessary. To run the code: 

mefimylaptop : ~$ . /Trigger_Only input_f ile . root data/TriggerCard.dat 

A.6. Running the FROG event display 

• If the FLAG_FROG was switched on in the smearing card, two files have been created during the running of Delphes: 
DelphesToFRDG . vis and DelphesToFROG . geom . They contain all the needed pieces of information to run FROG. 

• To display the events and the geometry, you first need to compile FROG. Go to the Utilities/FRDG and type make. This 
compilation is done once for all, with this geometry (i.e. as long as the *vis and *geom files do not change). 

• Go back into the main directory and type 

meSmylaptop: $ . /Utilities/FROG/FROG 

A.7. LHCO file format 

The *LHCG file format is a text-ASCII data format briefly discussed here. An exhaustive description is provided on 
http://vl.jthalernet/olympicswiki. This section is based on this webpage. Only final high-level objects are available in the LHCO 
format, and their properties are arranged in columns. Each row corresponds to an object in the event and all events are written after 
each other Comment-lines starts with a hash # symbol. 



# 


typ 


eta 


phi 


pt 


jmas 


ntrk 


btag 


had/em 


duml 


dum2 









57 























1 





1 


.392 


-2.269 


19.981 


0.000 





000 


0.000 


4.605 


0.000 





.000 


2 


3 


1 


.052 


2.599 


29.796 


3.698 


-1 


000 


0.000 


0.320 


0.000 





.000 


3 


4 


1 


.542 


-2.070 


84.308 


41.761 


7 


000 


0.000 


1.000 


0.000 





.000 


4 


4 


1 


.039 


0.856 


58.992 


34.941 


1 


000 


0.000 


1.118 


0.000 





.000 


5 


4 


1 


.052 


2.599 


29.796 


3.698 





000 


0.000 


0.320 


0.000 





.000 


6 


4 





.431 


-2.190 


22.631 


3.861 





000 


0.000 


1.000 


0.000 





.000 


7 


6 





.000 


0.845 


62 . 574 


0.000 





000 


0.000 


0.000 


0.000 





.000 
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Each row in an event starts with a unique number (i.e. in first column). Row contains the event number (here: 57) and some trigger 
information (here: 0. This very particular trigger encoding is not implemented in Delphes.). Subsequent rows list the reconstructed 
high-level objects. Each row is organised in columns, which details the object kinematics as well as more specific information, such 
as isolation criteria or ^-tagging. 

1st column ( #). The first column is the line number in the event. Each event starts with a and contains as many lines as needed to 
list all high-level objects. 

2yid column ( typ). The second column gives the object identification code, or type. The different object types are: 

for a photon (y) 

1 for an electron (e'^) 

2 for a muon (ju"^) 

3 for a hadronically-decaying tau (r-jet) 

4 for a jet 

6 for a missing transverse energy (is™'^^) 
Object type 5 is not defined. An event always ends with the row corresponding to the missing transverse energy (type 6). 

3rd ( eta) and4th (phi) columns. The third and forth columns gives the object pseudorapidity and azimuth 0. This latter quantity 
is expressed in radians, ranging from -n to tt. 

5th (pt) and 6th ( jmass) columns. The fifth column provides the object transverse momentum {pr in GeV/c) or energy (Et in 
GeV), while the invariant mass (M in GeV/c^) is in the sixth column. 

7th column ( ntrk). The seventh column reports the total number of tracks associated to the objects. This is for photons, ± 1 for 
charged leptons including taus (where the sign reports the lepton measured charge) and a positive number (> 0) for jets. 

8th column (btag). The eighth column tells whether a jet is tagged as a b-jet (1) or not (0). This is always for electrons, photons 
and missing transverse energy. For muons, the closest jet in searched for, in terms of AR. The integer-part of the quoted number is 
the row-number (column 1) of this jet. 

9th column ( had/em). For jets, electrons and photons, the ninth column is the ration between hadronic and electromagnetic energies 
in the calorimetric cells associated to the object. This is always for missing transverse energy. For muons, this number (aaa. bb) 
reports two values related to the muon isolation (section 3.1). The integer part (aaa) is transverse momentum sum Pj (in GeV/c) 
and the fractional part (bb) is the energy ratio p^. 

10th and 11th columns ( duml and dum2). The last two columns are currently not used. 

Warning. Inherently to the data format itself, the *LHCO output contains only a fraction of the available data. Moreover, dealing 
with text file may have various drawbacks, such as the output file size and the time needed for its creation. Whenever possible, 
working on the *root output file should be preferred. 
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